Multi-network token bin routing with defined verification parameters

ABSTRACT

Techniques described herein relate to using tokenization with BIN table routing by configuring a computer system, such as an acquirer computer, to utilize a token BIN translation table to determine which payment processing network(s) are eligible to route a transaction based upon a utilized token. In an embodiment, each token BIN translation table entry associates a token BIN with one or more payment processing networks that are eligible to route transactions. An acquirer computer, upon receiving a token for a transaction, thus may flexibly route the transaction to an eligible network from the set of payment processing networks identified by the entry corresponding to the token&#39;s BIN value. The entry may further identify verification methods for the eligible payment processing networks, and may identify product type attributes of the account associated with the token, either of which may be used in determining which payment processing network to select.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a non-provisional application and claims the benefitof priority of U.S. Provisional Application No. 61/893,761 titled“DIRECT TO NETWORK” and filed on Oct. 21, 2013, which is hereinincorporated by reference in its entirety for all purposes.

FIELD

Aspects of the disclosure relate to computing technologies. Inparticular, aspects of the disclosure relate to systems, methods,apparatuses, and computer-readable media for routing transaction datavia multiple payment processing networks using token BIN translationtable data including defined network verification parameters.

BACKGROUND

As the number of electronic transactions occurring in the worldcontinues to rise, it is increasingly difficult for the involvedentities, such as merchants and banks, to manage and process theseelectronic transactions and associated accounts efficiently andeffectively. Simultaneously, this complexity has further increased dueto ever-changing payment and network technologies and legislation.

In performing commercial electronic transactions, merchants and bankstypically have many credit networks and/or debit networks from which tochoose between, and a variety of rules that may bind certaintransactions to specific networks. Thus, determining the proper paymentprocessing network where a transaction may or should be processed canthus be particularly challenging, especially when a conflict existsbetween these types of rules, or when there are multiple options thatare available. Consequently, there is a need for improved systems andmethods for efficiently and effectively determining which network shouldbe used for processing a particular transaction.

Embodiments of the invention address these and other problems,individually and collectively.

BRIEF SUMMARY

Systems, methods, apparatuses, and computer-readable media are describedherein for using tokenization with BIN table routing. According to someembodiments, a token BIN value is associated with multiple paymentprocessing networks that are eligible to route transactions. In oneembodiment, a token BIN translation table is utilized that includes oneor more entries. Each entry maps a token BIN value to one or morepayment processing networks that are configured as eligible forprocessing transactions of the associated account. Thus, in someembodiments, a token BIN may be “globally” associated with a specificcombination of payment processing networks, and the token BIN may beselected for inclusion within a token purposefully based upon thedesired combination of desired eligible payment processing networks.Thus, in some embodiments a merchant and/or acquirer receiving a tokenwith a token BIN for a transaction will have the flexibility to routethe transaction to an eligible network from the combination of networkscorresponding to that token BIN.

In some embodiments, a single token BIN translation table entry mayidentify, for a token BIN, multiple payment processing networks that areeligible to process transactions for using that token BIN. The multiplepayment processing networks may include both credit processing networks,debit processing networks, or other types of processing networks (e.g.,hybrid networks for both credit and debit, etc.). In some embodiments, atoken BIN may be associated with multiple debit networks and multiplecredit networks.

According to an embodiment, a method is described that includesreceiving, at a computing device, a first transaction information for afirst transaction. The first transaction information includes a firsttoken value associated with a first account serving as a payment accountfor the first transaction. The first token value includes a token bankidentification number (BIN). The first transaction information does notinclude any primary account number (PAN) value of the first account. Themethod also includes identifying, by the computing device based upon thetoken BIN, a first entry of a plurality of entries of a token BINtranslation table. The first entry is associated with the token BIN andidentifies a plurality of payment processing networks that are eligibleto process transactions associated with the token BIN. The first entryfurther identifies a plurality of verification methods corresponding tothe plurality of payment processing networks. The method also includesselecting, by the computing device, a first of the plurality of paymentprocessing networks to process the transaction based at least in partupon the transaction information. The method further includestransmitting the transaction information to the selected first paymentprocessing network.

In some embodiments, at least one of the plurality of payment processingnetworks that are eligible to process transactions associated with thetoken BIN is a credit network, and at least one of the plurality ofpayment processing networks that are eligible to process transactionsassociated with the token BIN is a debit network.

In some embodiments, at least one of the plurality of verificationmethods indicates that the corresponding payment processing network is apersonal identification number (PIN) verification network, and at leastone of the plurality of verification methods indicates that thecorresponding payment processing network is a signature verificationnetwork. In some embodiments, one or more of the plurality ofverification methods are from an additional set of verification methodscomprising biometric verification, voice authentication, triangulationof multiple but unique characteristics of the consumer and their paymentcredentials, challenge-response authentication, two-factor verificationmethods used to verify a consumer's authorization to affect payments ortransact electronically, etc.

According to an embodiment, a non-transitory computer readable medium isdescribed that stores instructions which, when executed by one or moreprocessors of a computing device, cause the computing device to performoperations. The operations include receiving, at the computing device, afirst transaction information for a first transaction. The firsttransaction information includes a first token value associated with afirst account serving as a payment account for the first transaction.The first token value includes a token bank identification number (BIN).The first transaction information does not include any primary accountnumber (PAN) value of the first account. The operations also includeidentifying, by the computing device based upon the token BIN, a firstentry of a plurality of entries of a token BIN translation table. Thefirst entry is associated with the token BIN and identifies a pluralityof payment processing networks that are eligible to process transactionsassociated with the token BIN. The first entry further identifies aplurality of verification methods corresponding to the plurality ofpayment processing networks. The operations also include selecting, bythe computing device, a first of the plurality of payment processingnetworks to process the transaction based at least in part upon thetransaction information. The operations further include transmitting thetransaction information to the selected first payment processingnetwork.

According to an embodiment, a computing device is described thatincludes one or more processors, one or more network interfacescommunicatively coupled with the one or more processors, and anon-transitory computer readable medium that stores instructions which,when executed by the one or more processors, cause the computing deviceto perform operations. The operations include receiving, at the one ormore network interfaces of the computing device, a first transactioninformation for a first transaction. The first transaction informationincludes a first token value associated with a first account serving asa payment account for the first transaction. The first token valueincludes a token bank identification number (BIN). The first transactioninformation does not include any primary account number (PAN) value ofthe first account. The operations also include identifying, by the oneor more processors of the computing device based upon the token BIN, afirst entry of a plurality of entries of a token BIN translation table.The first entry is associated with the token BIN and identifies aplurality of payment processing networks that are eligible to processtransactions associated with the token BIN. The first entry furtheridentifies a plurality of verification methods corresponding to theplurality of payment processing networks. The operations also includeselecting, by the one or more processors of the computing device, afirst of the plurality of payment processing networks to process thetransaction based at least in part upon the transaction information. Theoperations further include transmitting, using the one or more networkinterfaces of the computing device, the transaction information to theselected first payment processing network. In some embodiments, thetransmission of the transaction information includes details necessaryto support the transport of verification information or the results of averification review process that may occur prior to transmission.

Accordingly, embodiments of the invention allow computing devices toconstrain the size of necessary transaction routing tables via use oftoken BIN translation tables that associate multiple eligible paymentprocessing networks with one token BIN. Thus, memory and processor usageis greatly reduced, and the system thus provides excellent scaling withincreased traffic and allows for additional applications/processes torun without jeopardizing transaction routing performance of theimplementing computing devices. Accordingly, embodiments can allow forflexible routing (e.g., allowing for the choice between multiple creditand/or debit networks) without the significant memory, processing, ornetwork overhead involved in other approaches that would require hugenumbers of routing table entries and frequent, bandwidth consuming,disruptive update processes. Moreover, in some embodiments, the logicrequired to be implemented for making routing decisions is greatlysimplified (and thus, the size and complexity logic is greatly reduced)as all or nearly all information required for decision making purposesis self-contained within the token BIN translation table itself.

The foregoing has broadly outlined some features and technical benefitsof examples according to the disclosure in order for the detaileddescription that follows to be better understood. Additional featuresand benefits will be described hereinafter. The conception and specificexamples disclosed can be readily utilized as a basis for modifying ordesigning other structures for carrying out the same purposes of thepresent disclosure. Such equivalent constructions do not depart from thespirit and scope of the appended claims. Features which are believed tobe characteristic of the concepts disclosed herein, both as to theirorganization and method of operation, together with associatedadvantages, will be better understood from the following descriptionwhen considered in connection with the accompanying figures. Each of thefigures is provided for the purpose of illustration and description onlyand not as a definition of the limits of the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a block diagram of entities in a payment transactionsystem employing multi-network token BIN routing according to anembodiment of the invention.

FIG. 2 illustrates a token BIN translation table including multipleentries associated token BINs with payment processing networks andverification parameters according to an embodiment of the invention.

FIG. 3 illustrates a combined sequence and flow diagram depictingtransaction routing using a token BIN translation table according to anembodiment of the invention.

FIG. 4 illustrates a flow in a merchant or acquirer computer forutilizing a token BIN translation table for selecting a paymentprocessing network according to an embodiment of the invention.

FIG. 5 illustrates a flow for configuring accounts with token BINs basedupon eligible payment processing networks and verification parametersaccording to an embodiment of the invention.

FIG. 6 illustrates a high level block diagram of a computer system thatmay be used to implement any of the entities or components describedherein.

DETAILED DESCRIPTION

Generally, a payment account number (or PAN) comprises a sixteen digitaccount number and is allocated in accordance with ISO/IEC 7812. Thesixteen digit account number may include a four or six digit IssuerIdentification Number (IIN) or Bank Identification Number (BIN), whichmay be a variable length account number of up to twelve digits and asingle check digit. The first digit of the six digits BIN may include aMajor Industry Identifier (MII), which represents the category of theentity that issued the payment account. For example, a value of the MIIdigit equal to 3, 4, 5, or 6 currently implies a banking or financialinstitution.

A BIN or IIN number may serve to identify the institution that issuedthe payment account to the account holder. For example, a BIN beginningwith a “4” may indicate that the associated issuing network as Visa®,whereas, a BIN range of 51-55 (i.e., all BIN values beginning with 51,52, 53, 54, or 55) may indicate that the associated issuing network isMasterCard®. Thus, different issuing networks may use different BINvalues and/or ranges to identify the network.

BIN values are often used to assist in determining how to “route”financial transaction data to an issuer of a payment account. Generally,merchants and acquirers utilize BIN (Bank Identification Number) tablesto determine which payment processing network is to be used to route atransaction. These BIN tables, also commonly referred to as BIN routingtables or BIN databases, often include entries that each map a BIN of anaccount to a particular processing network (or, to a specific endpointwithin the processing network within which it resides) to be used forrouting transactions having that BIN of an issuer. Thus, upon receipt oftransaction information (e.g., a payment authorization request message)from a merchant including a Primary Account Number (PAN) of an accountof the payer in the transaction, an acquirer may identify the BINportion of the PAN and use it as an index (or “key”) into the BIN tableto identify the processing network to be used to route the transactioninformation toward the correct issuer.

However, making routing decisions becomes complicated when tokenizationis utilized. Tokenization is a process of substituting sensitive data(e.g., a PAN of an account) with a non-sensitive equivalent referred toas a token. The token may comprise a same number of digits as theassociated PAN (e.g., each is sixteen digits in length) or may be adifferent length. Such tokens typically do not have any extrinsic orexploitable meaning or value, and thus, without access to the underlyingmapping between the token and the associated sensitive data, the tokenis meaningless. Thus, a token may be viewed as a reference or identifierthat can be mapped back to sensitive data. Accordingly, some paymentsystems are configured to utilize tokens instead of PANs, such that theexposure of the token to a third party is not particularly harmful. Forexample, an access device (e.g., a card processing terminal or Point ofSale (POS) terminal) may be configured to, upon receipt of a PAN from auser (e.g., via a swipe of a card, an entry via a website, or viacommunications with a payment device), generate a token “on-the-fly” anduse that token instead of the PAN within a payment authorization requestmessage. This token may only be “de-tokenized” (i.e., translated back tothe associated PAN) by the proper entity aware of the tokenizationscheme, such as an issuer of the account, a payment processing networkthat routes transactions of that account, or perhaps a third party tokenservices provider.

In some cases, the traditional “BIN portion” of the token (e.g., thelast four digits of a token) may match the “BIN portion” (e.g., the lastfour digits) of the associated PAN. In these cases, a merchant oracquirer could continue to use the BIN tables without any change, asrouting decisions would be based upon a same BIN value for either theactual PAN or the token.

However, some tokenization processes and/or tokenization systems may notmaintain the BIN portion of the associated PAN. In this case, oneapproach to continuing to utilize BIN tables includes adding, to the BINtables, BIN table entries mapping these token “BIN portion” values totheir designated networks. In these configurations, as unique tokens(and thus, potentially unique BIN portion values of the tokens) may begenerated very frequently (when compared to traditional PANs), this mayrequire BIN tables to be updated very frequently.

Additionally, with tokenization, supporting multiple payment processingnetworks for one underlying account is further complicated. As anexample, multiple tokens may be issued for one particular account, eachof which having a different BIN portion value to allow for multipledifferent payment processing networks to be deemed as eligible forrouting transactions associated with the account.

Thus, in some such embodiments, multiple BIN table entries are requiredto be placed within the BIN tables to correspond to the multiple BINportion values (of the multiple tokens) for the one account. Thus, ifone account is to be associated with six different payment processingnetworks, then six tokens may be issued for the account, and sixdifferent BIN portion values of those six tokens will be inserted as sixdifferent entries in a BIN table. For example, for a payment card numberstarting with “499999,” a token BIN may be generated as “412345” forrouting transactions through a first network, whereas another token BINmay be generated for the same payment account as “467890” for routingtransactions through a second network.

Therefore, BIN tables may include multiple entries for the same paymentaccount to accommodate different networks or combination of networks.For example, one entry for a first network may be for a signaturenetwork (e.g., Visa®, MasterCard®, American Express®, Discover®, etc.)and another entry for a second network may be a PIN (PersonalIdentification Number) network (e.g., Visa® debit, MasterCard® debit,STAR®, Interlink®, NYCE®, Maestro®, PULSE®, SHAZAM®, etc.). In order foracquirers and/or merchants to have the flexibility of choosing betweenmultiple eligible networks (e.g., signature, debit, PIN, etc., or anycombination thereof) for routing a transaction, and further for allowingmultiple “products” (e.g., a credit card, a debit card, a store card,etc.) to be associated with one account, it may require BIN tables to beof enormous size and require frequent updates.

As a result, in some instances, it may require significant time tosearch a BIN table for a pending transaction, thus adding delay tosomething (i.e., financial transaction processing) that is supposed tobe nearly instantaneous. For example, sometimes these larger and largerBIN tables do not completely fit in memory (e.g., RAM) that is “close”to the processor, and thus portions of the BIN tables may need to berepeatedly brought into memory from a “further” away memory such as asolid state or magnetic storage device, which is a relatively slowoperation. Moreover, performing frequent updates to these BIN tablesalso takes longer and longer to perform and continually requiresadditional computing resources (e.g., processing resources, networkresources, etc.), which can delay or negatively impact the “regular”workload of financial transaction processing.

Accordingly, systems, methods, apparatuses, and computer-readable mediaare described herein for implementing another approach to usingtokenization with BIN table routing. According to some embodiments, atoken BIN value is associated with multiple payment processing networksthat are eligible to route transactions for the payment account of thetransaction. In one embodiment, a token BIN translation table isutilized that includes one or more entries. Each entry maps a token BINvalue to one or more payment processing networks eligible for processingtransactions for that account. Thus, in some embodiments, a token BINmay be “globally” associated with a specific combination of paymentprocessing networks and purposefully selected for inclusion within atoken based upon the desired combination of networks. Thus, in someembodiments a merchant and/or acquirer receiving a transaction with atoken BIN will have the flexibility to route the transaction to aneligible network from the combination of networks corresponding to thattoken BIN.

According to some embodiments, token BINs (i.e., token issueridentifiers) are configured from a global, system-wide perspective toallow for routing logic to be “embedded” within tokens themselves. Thus,token BINs may be associated with particular combinations of networksthat are eligible to route transactions. Based upon these configuredassociations, token BINs may be purposefully identified and selected forinclusion within a token BIN based upon the desired combinations ofnetworks that are to be made eligible to route transactions using thattoken BIN. Accordingly, routing “logic” is thus embedded directly withinthe token itself in the form of this purposefully selected token BIN,and entities involved in routing such transactions (e.g., acquirercomputers, merchant computers, payment network computers, etc.) are ableto determine the routing option(s) based upon the received token BINitself. Additionally, this process does not impact other routingoperations and transaction processing performed by the entities in theentire system, as transactions may proceed as they typically do (e.g.,an issuer and/or a selected processing network may, upon receipt oftransaction information, perform a de-tokenization process to reveal theactual PAN, perform risk analysis procedures, determine aresult/decision for the transaction to be included within a paymentauthorization response message, etc.).

In some embodiments, a single token BIN translation table entry mayidentify, for a token BIN, multiple payment processing networks that areeligible to process transactions for using that token BIN. The multiplepayment processing networks may include both credit processing networks,debit processing networks, or other types of processing networks (e.g.,prepaid account payment processing networks, hybrid networks for bothcredit and debit, etc.). In some embodiments, a token BIN may beassociated with multiple types of networks (e.g., debit networks, creditnetworks, and prepaid networks), and/or multiple networks of aparticular type (e.g., multiple credit networks).

In some embodiments, some or all of the token BIN translation tableentries further include account attributes associated with the accountassociated with the token and thus, the utilized token BIN. The accountattributes may identify one or more “product types” (e.g., particularcard types or card “products”) associated with the account or card, andthus the entity utilizing the token BIN translation table may instantlydetermine the exact configuration (e.g., which products are associatedwith that card or account) of the payment card and/or account (insteadof needing to develop some sort of determination logic to infer orotherwise determine this information).

In some embodiments, based purely upon the entries of the token BINtranslation table, the entity utilizing the table (e.g., an acquiringbank, a merchant, and/or a processing network that may receivetransaction information but be required to forward it to the “proper”network of record) can programmatically determine which of the paymentprocessing networks are able to process transaction information fordifferent verification schemes. In some embodiments, one or moreverification schemes (or “cardholder verification schemes”) are definedand associated with a corresponding one or more payment processingnetworks within the token BIN translation table. A verification schemeidentifies which, if any, method of verifying the identity of theassociated user (i.e., the user presenting a physical or virtual paymentcard or otherwise providing payment for a transaction). For example, anillustrative but non-exhaustive list of verification schemes includes“signature” (e.g., where the user provides a signature at the time ofpurchase), “PIN” (e.g., where the user enters a PIN at the time ofpurchase), “biometric” (e.g., where a user provides biometric data forverification), “no signature” (e.g., where a user provides no PIN orsignature, and may instead be verified in another way), biometric, voiceauthentication, triangulation (e.g., of multiple but uniquecharacteristics of the consumer and their payment credentials),challenge-response, two-factor (or multi-factor) verification, etc.

Accordingly, embodiments of the invention allow computing devices toconstrain the size of necessary transaction routing tables via use oftoken BIN translation tables that associate multiple eligible paymentprocessing networks with one token BIN. Thus, memory and processor usageis greatly reduced and the system thus provides excellent scaling withincreased traffic and allows for additional applications/processes torun without jeopardizing transaction routing performance of theimplementing computing devices. Accordingly, embodiments can allow forflexible routing (e.g., allowing for the choice between multiple creditand/or debit networks) without the significant memory, processing, ornetwork overhead involved in previous approaches that required hugenumbers of routing table entries and frequent, bandwidth consuming,disruptive update processes. Moreover, in some embodiments, the logicrequired to be implemented for making routing decisions is greatlysimplified (and thus, the size and complexity of the underlying code isgreatly reduced) as nearly all information required for decision makingpurposes is self-contained within the token BIN translation tableitself.

Prior to discussing further embodiments of the invention with respect tothe figures, a description of some additional terminology is presentedto assist with the understanding this disclosure.

As used herein, the term “comprising” is not intended to be limiting,but may be a transitional term synonymous with “including,”“containing,” or “characterized by.” The term “comprising” may therebybe inclusive or open-ended and does not exclude additional, non-recitedelements or method steps when used in a claim. For instance, indescribing a method, “comprising” indicates that the claim is open-endedand allows for additional steps. In describing a device, “comprising”may mean that a named element(s) may be essential for an embodiment, butother elements may be added and still form a construct within the scopeof a claim. In contrast, the transitional phrase “consisting of”excludes any element, step, or ingredient not specified in a claim. Thisis consistent with the use of the term throughout the specification.

In the following description and claims, the terms “coupled” and“connected,” may be used. The term “coupled” may be used to indicatethat two or more elements, which may or may not be in direct physical orelectrical contact with each other, co-operate or interact with eachother. The term “connected” may be used to indicate the establishment ofcommunication between two or more elements that are coupled with eachother.

As used herein, a “mobile device” may comprise any electronic and/orcommunication device that may be transported and operated by a user,which may also provide remote communication capabilities with resourcescoupled to one or more networks. Examples of mobile devices includemobile phones (e.g. cellular phones), personal digital assistants(PDAs), tablet computers, net books, laptop computers, personal musicplayers, hand-held electronic reading devices, wearable computingdevices, etc.

A “server computer” may be a powerful computer or two or more computers.For example, the server computer can be a large mainframe, aminicomputer cluster, or a group of servers functioning as a unit. Inone example, the server computer may be a database server coupled to aweb server. Server computers often execute server applications that actas a server in client-server interactions, including but not limited todatabase server applications, web server applications, applicationserver applications, etc.

A “user” may be an entity, such as, an individual that may be associatedwith one or more payment accounts and/or mobile devices.

A “payment processing network” may include data processing subsystems,networks, and operations used to support and deliver certificateauthority services, authorization services, exception file services, andclearing and settlement services. An exemplary payment processingnetwork may include VisaNet™. Payment processing networks, such asVisaNet™, may be able to process credit card transactions, debit cardtransactions, and/or other types of commercial transactions. The paymentprocessing network may include one or more server computers. The paymentprocessing network may use any suitable wired or wireless network,including the Internet.

As used herein, payment or purchase “transaction data/information” mayrefer to any information corresponding to or describing purchases,orders, invoices, payments involving goods, items, services, and/or thelike, and may include, but is not limited to, a purchase amount, amerchant identifier, description code (e.g., NAICS: North AmericanIndustry Classification System) associated with purchased items, cost ofpurchased items, and transactions as well as descriptions of purchaseditems, purchase dates, purchase amounts, indications of paymentsaccounts used, indications of whether purchases were made online,confirmation numbers, order numbers, cancellation numbers, shipmentstatus updates (e.g., order being processed, shipped, delivered, on backorder, etc.), delivery tracking numbers, cancellation notices, updates,and/or the like.

As used herein, a “payment account” (which may be associated with one ormore payment devices) may refer to any suitable payment accountincluding a credit card account, a checking account, a prepaid account,etc.

As used herein, an “account identifier” may refer to a value thatuniquely identifies a payment account, which may be a payment accountinvolved in a transaction. An account identifier may be a PrimaryAccount Number (PAN) of an account, and may be defined according toISO/IEC 7812. Thus, some account identifiers may be numeric values, andhave 16, 17, 18, or 19 digits, for example. An account identifier mayalso include alphanumeric values, and may include only numeric digits,only alphabetic characters (possibly including other symbols such aspunctuation and mathematical symbols), or a combination of both numericdigits and alphabetic characters. Of course, other types ofrepresentations other than numeric digits and alphabetic characters mayalso be used within an account identifier. An account identifier mayinclude one or more of an issuer identifier, an individual accountidentifier, and a check digit.

As used herein, an “issuer identifier” may refer to a value thatidentifies a bank or entity that issued a payment account. For example,an issuer identifier may be a Bank Identification Number (BIN) or anIssuer Identification Number (IIN), and may include only numeric digits,only alphabetic characters, or combinations thereof. An issueridentifier may include six values/characters.

FIG. 1 illustrates a block diagram of entities in a payment transactionsystem 100 employing multi-network token BIN routing according to anembodiment of the invention. This depicted payment transaction system100 includes a user (not illustrated herein), optionally a paymentdevice 103 of the user, optionally a user device 112 (e.g., a mobiledevice such as a cellular telephone), an access device 102, a merchantcomputer 104, an acquirer computer 106 implementing a transactionrouting module 116, multiple payment processing networks 110A-110N, anissuer computer 118, and optionally a third party computer 124. In thisdepicted system, one or more of the payment processing networks110A-110N and/or one or more issuer computers 118 (others notillustrated for the sake of clarity) and/or a third party computer 124(e.g., a standards organization) may “publish” 160 a token BINtranslation table 108 or entries of the token BIN translation table 108,which is downloaded and stored (or otherwise accessed, such as via APIcalls) by the transaction routing module 116.

Throughout this description, the use of placeholder characters (e.g.,the “N” in payment processing network 110N) is not to be construed asrepresenting a particular set value. Thus, the “N” may indicate thatthere are five total payment processing networks, fifteen total paymentprocessing networks, fifty total payment processing networks, etc.

The system 100 comprises a user who may operate a user device 112. Theuser may use the mobile device 112 to conduct a financial transaction(e.g., perform a payment transaction) at an access device 102 thatitself is communicatively coupled with a merchant computer 104. The usermay also use a payment device 103 at the access device 102 (e.g.,“swipe” or present the payment device 103) to conduct the financialtransaction. Merchant computer 104 may be connected, via one or morecommunication networks, to acquirer computer 106. Acquirer computer 106may itself be communicatively coupled with one or more issuer computers(e.g., issuer computer 118) via one or more payment processing networks(e.g., network 110A—network 110N). Of course, some or all of theseentities depicted as communicatively coupled may be connected via one ormore communication networks or may be directly connected.

As used herein, a “merchant” is typically an entity that engages intransactions and may sell goods and/or services. An “issuer” maytypically refer to a business entity (e.g., a bank) that maintainsfinancial accounts for users and may issue payment credentials to bestored on a user device 112 (e.g., a cellular telephone, smart card,tablet, laptop, etc.) of a user. An “acquirer” is typically a businessentity (e.g., a bank) that has a business relationship with a particularmerchant or other entity. Some entities can perform both issuer andacquirer functions, and some embodiments may encompass such singleentity issuer-acquirers. Each of the entities (e.g., merchant computer104, acquirer computer 106, payment processing networks 110A-110N, andissuer computer 118, third party computer 124) may comprise one or morecomputer apparatuses to enable communications or to perform one or moreof the functions described herein.

As used herein, a “payment device” 103 may refer to any device that maybe used to conduct a financial transaction, such as to provide paymentinformation to a merchant. A payment device may be in any suitable form.For example, suitable payment devices include, but are not limited to,smart cards, magnetic stripe cards, keychain devices (such as theSpeedpass™ commercially available from Exxon-Mobil Corp.), cellularphones, personal digital assistants (PDAs), pagers, payment cards,security cards, access cards, smart media, transponders, 2-D barcodes,an electronic or digital wallet, and the like. Such devices can operatein either a contact or contactless mode. In some configurations, apayment device 103 directly interacts with an access device 102 (i.e.,without the use of any other device and/or network), but in someconfigurations payment device 103 communicates with the access device102 using an intermediary device and/or a communication network. Userdevice 112 may be a mobile device (as described above) that, in someembodiments, may be thought of as a type of payment device (e.g.,payment device 103). For example, a user device 112 may include, but isnot limited to, a cellular phone, laptop, tablet, wearable computingdevice, etc., and may interact with an access device 102 (e.g., usingNFC) and/or merchant computer 104 (e.g., via the Internet to access awebsite or utilize an application provided by merchant computer 104) toinitiate and/or conduct a financial transaction. The user device 112 mayalso utilize a payment application 114 including account credentialsprovisioned by (or, in part by) issuer computer 118 during thetransaction.

In some embodiments, the payment processing networks 110A-110N mayconduct transactions in substantially real-time (e.g., in fewer than afew seconds or fractions of a second). The payment processing networks110A-110N may include one or more server computers (as described above),and may use any suitable wired or wireless network, including theInternet.

In an exemplary purchase transaction, the user purchases a good orservice from a merchant using a user device 112 (e.g., a mobile phone).The user's device 112 can interact with an access device 102 at amerchant associated with merchant computer 104. For example, the usermay tap the user device 112 against an NFC reader in the access device102. Alternatively, the user may provide payment details to the merchantelectronically, such using a digital wallet (e.g., payment application114) or through an online transaction, and these details may be providedto the merchant via the access device 102. In some purchase transactionsthe user device 112 may not utilize an access device 102, and mayinstead “directly” interact with a merchant computer 104 (e.g., acomputing system providing a merchant website or “backend” services fora merchant application executing on the user device 112). In theseexamples, the merchant computer 104 may be thought of as implementing avirtual access device.

To cause the financial transaction to be performed, transactioninformation 152 (including a token) such as an authorization requestmessage may be generated by the access device 102 (or virtual accessdevice, which may be at merchant computer 104) and be forwarded to theacquirer computer 106.

In some embodiments, the token is “pre-generated” and stored by thepayment device 103 or user device 112, and thus is provided to theaccess device 102 or merchant computer 104 for inclusion within thetransaction information 152. In some embodiments, though, the token isgenerated “on-the-fly” (or, on demand for a particular transaction ortransactions) by the payment device 103 (e.g., when payment device 103comprises a chipcard), user device 112 (e.g., when the paymentapplication 114 includes token generation logic), by the access device102 using a provided PAN, or by the merchant computer 104 using aprovided PAN. Thus, the acquirer computer 106 receives transactioninformation 152, such as an authentication request message, thatincludes a token (and thus, a token BIN).

The acquirer computer 106 is a system of an acquirer (as discussedabove) providing an account of the merchant, which will ultimatelyreceive the funds for the transaction from an issuer providing theuser's account. The transaction information 152, or “authorizationrequest message”, received by the acquirer computer 106 may be anelectronic message that is sent via a payment processing network 110Aand/or an issuer of a payment card (e.g., issuer computer 118) torequest authorization for a transaction. An authorization requestmessage, according to some embodiments, may comply with a message typedefined by the International Organization for Standardization (ISO) 8583standard, which is a standard for systems that exchange electronictransaction information associated with payments made by users using apayment device 103 (which could be a user device 112) or paymentaccount. In addition to including a token, an authorization requestmessage may also comprise additional data elements corresponding to“identification information” including, by way of example only: aservice code, a CVV (card verification value), a dCVV (dynamic cardverification value), an expiration date, a cryptogram, etc. Anauthorization request message may also include other transactioninformation, such as any information associated with a currenttransaction, such as the transaction amount, merchant identifier,merchant location, etc., as well as any other information that may beutilized in determining whether to identify and/or authorize atransaction. The authorization request message may also include otherinformation such as an identifier of the access device 102 thatgenerated the authorization request message, information about thelocation of the access device 102, etc.

Typically, an authorization request message will include a field for aprimary account number (PAN) associated with an account of the user thatwas provided by the user device 112 (or payment device 103), though thisPAN field will, in some embodiments, include the token instead of theactual PAN.

After receiving the transaction information 152 (which may or may not bean authorization request message), the acquirer computer 104 will seekto “route” the transaction information by sending transactioninformation 156 (which may or may not be an authorization requestmessage) to a particular payment processing network (e.g., paymentprocessing network 110B). This transaction information 156, in someembodiments, includes some or all of the received transactioninformation 152, and in some embodiments, the transaction information156 may include additional information that may be generated (orseparately received) by the acquirer computer 104. For example, in someembodiments the acquirer computer 104 may perform its own verificationreview process for the transaction, and may include, with thetransaction information 156, the results of the verification reviewprocess. As one example, a verification review process may determine aperceived risk of the transaction based upon the received transactioninformation 152 (e.g., based upon authentication data), and a resultingscore may be generated and included with the forwarded transactioninformation 156.

In some embodiments, the transaction routing module 116 of the acquirercomputer 106 identifies the token BIN within the token received with thetransaction information 152, and uses this identified token BIN todetermine which (of possibly multiple) payment processing networks110A-110N to route the transaction information 156 through. In someembodiments, this includes using the token BIN as a sort of a “key” or“index” into the token BIN translation table 108 to identify an entry ofthe token BIN translation table 108. In an embodiment, the entryidentifies one or more of the payment processing networks 110A-110N thatare deemed eligible to route the transaction. In some embodiments, theentry further defines verification parameters associated with theidentified payment processing networks 110A-110N. In some embodiments,the entry further identifies one or more account attributes 208 (such asproduct type attributes 206 used by the account(s) having thatparticular token BIN).

With this data from the identified entry of the token BIN translationtable 108, the transaction routing module 116 is able to determine whichof the payment processing networks 110A-110N to route the transactioninformation 156 to. In some embodiments, this determination is basedupon information within the received transaction information 152, suchas an indication of whether the transaction was submitted (e.g., by theuser, by the access device 102, etc.) as a debit or credit transactionand/or whether it was submitted using a provided PIN value, a signature,etc. Determining such logic for selecting between the identifiedeligible payment processing networks 110A-110N is thus highlyconfigurable based upon the preferences of the particular acquirer, andis easy to implement because of the large amount of informationexplicitly provided via the identified token BIN translation table 108entry. Thus, the particular logic used is allowed to be tremendouslyflexible and may be implemented according to the desires of theparticular acquirer 106 by one of ordinary skill in the art.

The payment processing network 105 then forwards the transactioninformation 158 (including a token, or perhaps including a PAN that wasde-tokenized by that network or a token service provider, for example)to the issuer computer 118 associated with the issuer of the user'saccount.

After the issuer computer 118 receives the transaction information 158(e.g., an authorization request message), the issuer computer 118 sendstransaction response information (e.g., an authorization responsemessage) back to the payment processing network to indicate whether ornot the current transaction is authorized. Such transaction responseinformation is not illustrated herein to avoid obscuring aspects of someembodiments, but may be easily implemented by those of ordinary skill inthe art. An “authorization response message” may be an electronicmessage reply to an authorization request message generated by anissuing financial institution or a payment processing network, and maycomply with the ISO 8583 standard. The authorization response messagemay include, by way of example only, one or more of the following statusindicators: Approval—transaction was approved; Decline—transaction wasnot approved; or Call Center—response pending more information, themerchant must call the toll-free authorization phone number. Theauthorization response message may also include an authorization code,which may be a code that an issuer returns in response to anauthorization request message in an electronic message (either directlyor through the payment processing network) to the merchant's accessdevice 102 (e.g., a POS terminal) that indicates an approval of atransaction, and may serve as proof of authorization.

The payment processing network (e.g., network 110A) receives thetransaction response information (e.g., authorization response message)from the issuer computer 106 and transmits it back to the acquirercomputer 106. The acquirer computer 106 then sends the transactionresponse information (e.g., authorization response message) back to themerchant computer 104, where the merchant can determine whether toproceed with the transaction. In some embodiments, such as when a fraudrule is triggered by the payment processing network, the paymentprocessing network (e.g., network 110A) may itself decline a transactionpreviously authorized by issuer computer 118. Regardless, after themerchant computer 104 receives the transaction response information(e.g., authorization response message), the access device 102 may thenprovide a response message for the user. The response message may bedisplayed by a display device (e.g., a display device that is part of orcoupled to the access device 102), printed out on a receipt,communicated to the user's device 112, etc. Alternately, if thetransaction is an online transaction (e.g., via a website orapplication), the merchant computer 104 may provide a web page, displaymodule, or other indication of the transaction response to the userdevice 112.

At the end of the day, a normal clearing and settlement process may beconducted by the utilized payment processing network 110A. A clearingprocess is a process of exchanging financial details between an acquirerand an issuer to facilitate posting to a user's payment account andreconciliation of the user's settlement position. However, it should benoted that embodiments of the invention are not limited to such a singlesettlement process.

As described above, techniques described herein uniquely enablemulti-network routing (i.e., allowing for multiple eligible paymentprocessing networks) for transactions utilizing tokens (and thus, tokenBINs) without employing the use of translation tables with large memoryrequirements, frequent updates, large per-transaction processingrequirements, etc. Moreover, techniques described herein allow foracquirers to easily and simply develop lightweight and customizedrouting logic (e.g., via transaction routing module 116) that canheavily rely upon the token BIN translation table 108 data.

Having discussed some of the entities involved in a payment system 100utilizing a token BIN translation table 108, we now turn to an exemplarytoken BIN translation table 108. FIG. 2 illustrates a token BINtranslation table 108 including multiple entries that associate tokenBINs with payment processing networks and verification parametersaccording to an embodiment of the invention. The token BIN translationtable 108, in some embodiments, is stored and accessed by the acquirercomputer 106 via its transaction routing module 116. In someembodiments, the token BIN translation table 108 is stored at one ormore of the merchant computer 104, the acquirer computer 106, the thirdparty computer 124, any of the networks 110A-110N, and the issuercomputer 118.

The illustrated token BIN translation table 108 is shown as includingtwelve entries, ten different payment processing networks 110A-110K andverification scheme parameters 210, one set of account attributes 208(i.e., product type attributes 206), and twelve types of product typeattributes 206. Of course, more or fewer of these elements may be usedin other token BIN translation tables 108 depending upon the operatingenvironment and the particular embodiment.

The illustrated token BIN translation table 108 includes a first set ofentries 202 associated with a first issuer ‘A’, and a second set ofentries 204 associated with a second issuer ‘B’. In some embodiments,each of these entries are directly “published” 160 by the respectiveissuer, but in some embodiments these entries are published 160 by acommon entity, such as an external organization (e.g., third partycomputer 124) or one of the issuers (e.g., issuer computer 118). In someembodiments, these entities may be published 160 by one or more of thepayment processing networks 110A-110N themselves, or may be published160 by combinations of the payment processing networks 110A-110N,issuers, and third parties.

This token BIN translation table 108 includes a first column of tokenBIN values 212—some of which 202 are associated with a first issuer, andsome of which 204 are associated with a second issuer. In thisembodiment, each token BIN comprises a six digit value. Accordingly, thetransaction routing module 116, upon receipt of transaction informationincluding a token, will identify the token BIN portion of the token, andmay use it as an index into the token BIN translation table 108 bysearching for a “matching” entry.

Although this depiction shows that each entry includes a “compete” tokenBIN, in some embodiments “ranges” (or even non-consecutive groupings) oftoken BINs may be associated with one entry. Thus, a token BIN may be a“partial” token BIN and/or include placeholder values (i.e., an asteriskrepresenting a wildcard, for example). For example, an entry in thetoken BIN 212 column may represent all token BINs between 412010 and412060 (and perhaps be represented as 41201*-41206*), or all token BINsbetween 410000 and 419999 (perhaps being represented as 41*), or agrouping of two token BINs (perhaps represented as 412345; 412456).Thus, one entry may correspond to exactly one token BIN, or correspondto potentially many token BINs.

Based upon identifying a matching entry using the received token BIN,one or more payment processing networks 110A-110K configured as eligibleto process transactions for that particular BIN may be identified. Forexample, the seventh entry 203 indicates that four networks areconfigured as eligible for process transactions for the token BIN of“435432”: payment processing network ‘A’ 110A, payment processingnetwork ‘B’ 110B, payment processing network ‘E’ 110E, and paymentprocessing network ‘G’ 110G. In this depicted example, these paymentprocessing networks of the seventh entry 203 include two paymentprocessing networks having a “signature” verification scheme parameter210 (i.e., networks ‘A’ 110A and ‘B’ 110B) and two payment processingnetworks having a “PIN” verification scheme parameter 210 (i.e.,networks ‘E’ 110E and ‘G’ 110G). Thus, in some embodiments, thetransaction routing module 116 may be flexibly configured with logicnecessary to select one of these networks according to the implementingacquirer's requirements. For example, assuming this seventh entry 203 isthe identified entry for a transaction, the logic may be configured toidentify which, if any, verification scheme was employed when thetransaction was initiated (by the user and/or access device 102 and/ormerchant computer 104) based upon the received transaction information,which may include an identifier of the utilized verification scheme, andthen select (based upon the acquirer's requirements/preferences) betweenthe eligible payment processing networks with a correspondingverification scheme parameter 210 indicator in the token BIN translationtable 108 matching that particular used scheme.

In some embodiments, the decision between the eligible paymentprocessing networks 110A-110K for an entry may be made based upon theaccount attributes 208 stipulated in the token BIN translation table108. For example, in an embodiment including product type attributes 206in the token BIN translation table 108, the logic may be configured toselect different networks based upon the value of that entry's producttype attributes 206 (represented herein as TYPE ‘1’, etc., which servesas a placeholder for any type of identifier of one or more product typeattributes).

In some embodiments, a product type may identify an issuer of thecard/account (e.g., “Visa®”). However, a product type may furtherspecify one or more particular card products associated withcard/account. Over the years, card issuers have developed different card(or “product”) types to more effectively target a variety of customersegments to serve customer needs and increase card usage at the sametime. For Visa® credit cards, for example, product types may includeVisa® Traditional, Visa® Traditional Rewards, Visa® Signature, Visa®Signature Preferred, among many others. Thus, in some embodiments, oneor more of the entries of the token BIN translation table 108 mayidentify one—or more—product types of the associated card/account as theproduct type attributes 206.

Of course, other account attributes may also be identified or stored bythe entries of the token BIN translation table 108. For example, theentries may identify account enhancement attributes (not illustrated)for the corresponding cards/accounts using that particular token BIN. Insome embodiments, the cards/accounts may have a different set ofenhancement features assigned to it. Enhancement features are servicesor goods that a card issuer may provide in addition to processingpurchase transactions of the cardholders. Examples of enhancementfeatures include zero liability from loss of card, auto rental collisiondamage waiver, emergency cash disbursement and card replacement,lost/stolen card reporting, extra warranty period for products, travelaccident insurance, lost luggage reimbursement, roadside dispatch, cashback and frequent flyer mileage. Such enhancement features may beidentified by a set of account enhancement attributes in the token BINtranslation table 108, and may be used within the eligible paymentprocessing network selection logic for the purposes of selecting whicheligible payment processing network for a particular entry is to be usedto route the transaction information for a particular transaction.

Although this table is depicted is a single data structure, in someembodiments the table is made up of multiple data structures. As oneexample, the token BINs 212, in some embodiments, may not be literallystored in a data structure. Instead, for example, a hash table (or “hashmap” or similar data structure) might be used in some embodiments to“hash” a received token BIN to identify an entry of the token BINtranslation table. Alternatively, a separate “mapping” structure maystore the actual token BINs 212 and map them to identifiers (e.g., amemory address, for example) of entries in one or more separate datastructures identifying the account attributes 208 and/or eligiblepayment processing networks 110A-110K and/or verification schemeparameters 210.

Similarly, although checkmarks are depicted herein for ease ofunderstanding, these checkmarks may, in some embodiments, be stored asbinary values (indicating a 0 or 1, which may be referenced as a True orFalse) within a table. In some embodiments, the “eligible” paymentprocessing networks 110A-110K for an entry may instead be stored as alist of network identifiers. For example, the first depicted entry(identifying networks 110A, 110B, 110E, 110H, and 110J as eligiblenetworks) may have a set of eligible payment processing networks110A-110K represented as “{A, B, E, H, J}”, where these elements may beany type of identifier of a respective payment processing network. Thus,the particular depiction of this illustrative token BIN translationtable 108 presents just one of many possible implementations ofembodiments described herein, and many variants may be readilydetermined and implemented by those of skill in the art using thisdescription provided herein.

An exemplary flow for utilizing token BIN translation table inmulti-network token BIN routing is now presented. FIG. 3 illustrates acombined sequence and flow diagram 300 depicting transaction routingusing a token BIN translation table according to an embodiment of theinvention. FIG. 3 depicts some possible actions performed by andmessages exchanged between various entities in a payment system, whichincludes a user device 112, access device 102, merchant computer 104,acquirer computer 106 (with a transaction routing module 116), a paymentprocessing network ‘X’ 110X, an issuer computer 118, and a third partycomputer 124. Of course, this diagram illustrates just one embodiment ofmany possible systems and configurations of other embodiments. As oneexample, user device 112 may instead be a payment device 103 in someembodiments. As another example, the third party computer 124 may notexist in some embodiments. Thus, this example is intended to beillustrative of just one of many embodiments.

The embodiment of this diagram 300 may include one—or more—of thenetwork ‘X’ 110X (and possibly, other of the payment processing networks110A-110N), the issuer computer 118 (and possibly, other issuercomputers of the same issuer or different issuers), and the third partycomputer 124 publishing 302 entries to the token BIN transaction table.For example, in some embodiments, one of the issuers (e.g., via issuercomputer 118) may configure a token BIN to be associated with one ormore payment processing networks, and may cause an entry for that tokenBIN to be “published” at block 302. In some embodiments, this publishing302 includes sending data for the entry (e.g., the token BIN or tokenBIN range, eligible payment processing network identifiers, associatedverification parameters, account attributes, etc.) to another computingdevice. For example, this data may be sent to the third party computer124, which itself will provide entry data for token BIN translationtables to other computing systems, such as one or more acquirercomputers 106. In other embodiments, though, the publishing 302 mayinclude directly transmitting data for the entry to an acquirer computer106, which may or may not occur in response to a request for token BINtranslation table entry data received from the acquirer computer 106. Ofcourse, other configurations are possible, including one or more paymentprocessing networks 110A-110N “publishing” this entry data, and/or thethird party computer 124 “publishing” this entry data. Similarly, insome embodiments the token BIN translation table entries may also beutilized by, and thus “published to”, the merchant computer 104, one ormore of the payment processing networks 110A-110N, one or more issuercomputers 118, etc.

At some point, a user initiates a transaction with a merchant, and atoken will be used (and possibly generated) for the transaction. Thismay occur in a variety of ways. For the purposes of this discussion, theuser device 112, in some embodiments, is instead a payment device 103.

In some embodiments, the user device 112 provides a token 304 for thetransaction. For example, at block 304, the user device 112 may generatea token at block 304 for the particular transaction (or, perhaps, notspecific to any one transaction), and provide (via arrow 350) the tokento an access device 102, or provide the token at arrow 354 directly tothe merchant computer 104. Alternatively, the user device 112 may have apreviously provisioned (or generated) token, and may provide that token(at arrow 350) to the access device 102 or (at arrow 354) to themerchant computer 104.

In some embodiments, the access device 102 generates the token (at block306). For example, the user device 112 may present a PAN (at arrow 350)to the access device 102, which may be configured to, possibly basedupon that PAN, generate a token for the transaction, and pass the token(at arrow 352) to the merchant computer 104 for payment processing(along with transaction data).

In some embodiments, though, the user device 112 provides a PAN for thetransaction (at arrow 350), and the access device 102 passes that PANwith transaction data (at arrow 352) to the merchant computer 104. Themerchant computer 104, then, may be configured to generate a token atblock 308 for the transaction.

Moving on, eventually the merchant computer 104, in this depictedembodiment, will be in possession of a token associated with the user'spayment account that is to be used for the transaction. At arrow 356,the merchant computer 104 may provide the transaction information—whichmay be a payment authorization request, for example—to an acquirercomputer 106. This transaction information includes the token, and insome embodiments, does not include the PAN of the payment account.

Upon receipt of the transaction information (depicted as arrow 356), theacquirer computer 106 may then, in the depicted embodiment, identify atblock 310 a set of eligible payment processing networks and verificationparameters associated with the token BIN. In some embodiments, thisidentification includes identifying the token BIN from the receivedtoken, and using the token BIN as an index into a table (or other datastructure) identifying one or more eligible payment processing networksthat are able to route transactions for that token BIN. In someembodiments, the table (or data structure) further identifies, for eachof the identifying one or more eligible payment processing networks, averification parameter employed for the respective network. Further, insome embodiments, the table (or data structure) further associates, forone or more token BINs, one or more product type attributes for eachtoken BIN, where the product type attributes identify one or more cardproduct types associated with the card/account used the in thetransaction and for which the token (and token BIN) is associated with.In some embodiments, the table (or data structure) may comprise a tokenBIN translation table including a multiple entries, and at least one ofthe multiple entries identifies multiple eligible payment processingnetworks that can route transactions associated with the token BIN.

The acquirer computer 106, in this depicted embodiment, selects onepayment processing network at block 312 from the identified set ofpayment processing networks deemed eligible for routing transactionsassociated with the token BIN (at identified in block 310). In someembodiments, this selection is based at least upon the transactioninformation received from the merchant computer 104 at arrow 356, whichmay include an identifier of how the account information (e.g., PAN ortoken) was received or generated, whether the transaction is anin-person transaction (i.e., the user was physically proximate to theaccess device 102 or merchant location), whether the user provided asignature or PIN, etc. For example, in some embodiments the acquirercomputer 106 may be configured to determine whether the transactioninformation 356 identifies what type of verification data may have beenprovided by the user, and select one of the eligible payment processingnetworks configured with that particular verification scheme.Additionally, this determination, in some embodiments, may be based uponone or more of an expected cost of routing the transaction over theidentified eligible networks, a number of previous transactionstransmitted over the identified eligible networks, the value of theproduct type attributes associated with the token BIN, and flexibly, anyother factors deemed relevant to the particular implementation and/oracquirer preference.

In some embodiments, the operations of block 310 and block 312 may beperformed at once and thus they effectively collapse into a singleblock. Thus, in some embodiments, the acquirer computer 106 may beconfigured to immediately select a payment processing network from a setof eligible payment processing networks without needing to distinctlyfirst explicitly identify that set. This may occur, for example, if theacquirer computer 106 queries the token BIN translation table using thetoken BIN as well as another selection option, such as a definedverification parameter, to possibly identify precisely one eligiblepayment processing network associated with the token BIN.

When an payment processing network that is eligible to routetransactions having the token BIN has been selected, the transaction mayoccur using “traditional” token-based payment processing operations. Forexample, the acquirer computer 106 transmits transaction information 358(which may or may not be the same transaction information received atarrow 356) at arrow 358 to the selected network—here represented bynetwork ‘X’ 110X. This network ‘X’ 110X may, based upon the transactioninformation (e.g., the token) identify the issuer and forward thetransaction information—possibly modified, as a result of the network'sown risk analysis, for example, or including a PAN resulting from ade-tokenization of the token—at arrow 360 to that issuer. The issuercomputer 118, then, may determine whether the transaction may proceed,and will transmit a transaction response message (e.g., a paymentauthorization response message) at arrow 362 back through the network110X, to the acquirer computer 106 at arrow 364, to the merchantcomputer 104 at arrow 366, and to the access device 102 at arrow 368. Insome embodiments, some or all of the transaction response messages 362,364, 366, and 368 are different messages that may include differentinformation, though, in some embodiments, all are related to thetransaction and in some way indicate whether the transaction isauthorized.

FIG. 4 illustrates a flow 400 in a merchant or acquirer computer forutilizing a token translation table (e.g., token BIN translation table)for selecting a payment processing network according to an embodiment.In some embodiments, flow 400 is performed by the transaction routingmodule 116 of the acquirer computer 106, and in some embodiments theflow 400 is performed by a merchant computer 104.

The flow includes 400, at block 405, receiving transaction informationfor a transaction. In an embodiment, the transaction informationincludes a token value associated with an account serving as a paymentaccount for the transaction. The token value includes a token issueridentifier (e.g., a token BIN), and the token information does notinclude any account identifier (e.g., primary account number (PAN)) ofthe account 405. In some embodiments, the transaction informationcomprises a payment authentication request message. In some embodiments,the transaction information was received from a merchant computer, andin some embodiments the merchant computer generated the token based uponan account identifier (e.g., a PAN) provided by the user for thetransaction. However, in some embodiments the token was provisioned ontoa user device 112 that the user utilized for the transaction, and insome embodiments the user device 112 itself generated the token, and insome embodiments an access device 102 that received an accountidentifier (e.g., a PAN) for the transaction itself generated the token.

The flow 400 also includes, at block 410, identifying, based upon thetoken issuer identifier (e.g., token BIN) from the token, an entry of aplurality of entries of a token translation table (e.g., token BINtranslation table). The entry identifies a plurality of paymentprocessing networks that are eligible to process transactions associatedwith the token issuer identifier (e.g., token BIN). The entry furtheridentifies a plurality of verification methods corresponding to theplurality of payment processing networks. In some embodiments one ormore of the verification methods is “signature,” “PIN,” or“no-signature.” In some embodiments, the identifying includes using thetoken issuer identifier as an index into the token translation table toidentify the entry.

At block 415, one of the plurality of payment processing networks isselected to process the transaction based at least in part upon thetransaction information. In some embodiments, this selection is basedupon a verification scheme performed at the time of the initiation ofthe transaction by the user, and may include, in some embodiments, anindicator within the transaction information identifying whether theuser provided a signature, PIN, “no signature”, other identityinformation such as a government issued license, used a chipcard, etc.

For example, in some embodiments, block 415 may include block 450, wherethe flow 400 includes determining, based upon the transactioninformation, what payment type or verification scheme was used for thetransaction. Then, at decision block 455, the flow continues based uponhow many of the payment processing networks of the identified entry havea matching payment type parameter or verification parameter. When thereis exactly one matching eligible payment processing network, flowcontinues to block 460, where that one matching eligible paymentprocessing network is selected to process the transaction. However, whenthere are more than one of the payment processing networks of theidentified entry that have a matching payment type parameter orverification parameter, though, flow continues to block 465, where oneof these entries is selected according to one or more defined selectionrules. In an embodiment, the selection rules may indicate logicconstituting an order for selecting between some or all of the paymentprocessing networks.

The flow 400, at block 420, includes transmitting the transactioninformation to the selected payment processing network. In someembodiments, the flow 400 further includes receiving a response message(e.g., a payment authorization response message) indicating whether theissuer of the user's account will authorize the transaction.

In contrast to the flow 400 of FIG. 4, FIG. 5 illustrates a flow forconfiguring accounts with token BINs based upon eligible paymentprocessing networks and verification schemes according to an embodimentof the invention. In some embodiments, some or all of these blocks505-535 may be performed by one or more of a payment processing network(e.g., network 110A), an issuer (e.g., issuer computer 118), and a thirdparty computer 124.

The flow 500 includes, at block 505, determining a need to configurepayment processing for one or more accounts. In an embodiment, thisoccurs responsive to the creation of a new account or the configurationof an account with one or more product types.

At block 510, the flow 500 includes determining one or more paymentprocessing networks and associated verification schemes to be madeeligible for processing transactions associated with the account(s). Inan embodiment, the one or more payment processing networks andassociated verification schemes are identified based upon the producttype or types associated with the account.

At decision block 515, the flow 500 includes determining whether anypublished token BIN translation table entry corresponds to thedetermined networks and verification schemes. In an embodiment, thisblock 515 includes searching a token BIN translation table for anyentries having exactly the same configuration of determined networks andverification schemes. In some embodiments, block 515 includes searchinga token BIN translation table to determine whether any entry includes asame set of product type attributes as are associated with the one ormore accounts.

If a table entry is found at block 515, flow continues with block 520,where the token BIN associated with that token BIN translation tableentry is identified.

In contrast, if no table entry is found at block 515, flow continueswith block 525, where a token BIN is selected to be used for the one ormore accounts, and block 530, where a token BIN translation table entryis published for the selected token BIN that has the determined networksand verification parameters.

Regardless of the path, flow continues with block 535, in which theselected token BIN is caused to be used as the BIN value within tokensthat will be generated for the one or more accounts. In someembodiments, this includes block 540, where one or more paymentapplications (e.g., payment application 114) are configured to generatetokens for those accounts using the selected token BIN. In someembodiments, block 535 includes block 545, where one or more accessdevices (e.g., access device 102) is configured to generate tokens usingthe selected token BIN upon receipt of PANs associated with thoseaccounts. Further, in some embodiments, block 535 includes block 550,where token generation logic is configured to generate tokens for thoseaccounts. The token generation logic may exist in a variety oflocations, including but not limited to token generation module of atoken service provider, a credential provisioning server, an accountmanagement module of the issuer computer 118, etc.

The various participants and elements described herein may operate oneor more computer apparatuses to facilitate the functions describedherein. Any of the elements in the above-described FIGS. 1-5, includingany servers or databases, may use any suitable number of subsystems tofacilitate the functions described herein.

Examples of such subsystems or components are shown in FIG. 6. FIG. 6illustrates a high level block diagram of a computer system that may beused to implement any of the entities or components described herein.The subsystems shown in FIG. 6 are interconnected via a system bus 602.Additional subsystems include a printer 610, keyboard 618, fixed disk620, and monitor 612, which may be coupled to display adapter 614.Peripherals and input/output (I/O) devices, which couple to I/Ocontroller 604, can be connected to the computer system by any number ofmeans known in the art, such as a serial port, USB port, IEEE 1394(i.e., Firewire) port, external Serial Advanced Technology Attachment(eSATA) port, or similar port. For example, serial port 616 or externalinterface 622 can be used to connect the computer apparatus, throughwired or wireless communications, to a wide area network (WAN) such asthe Internet, a mouse input device, or a scanner. The interconnectionvia system bus 602 allows the central processor 608 to communicate witheach subsystem and to control the execution of instructions from systemmemory 606 or the fixed disk 620, as well as the exchange of informationbetween subsystems. The system memory 606 and/or the fixed disk 620 mayembody a computer-readable medium. For example, the fixed disk 620 maybe implemented, for example, as a hard drive, flash drive (e.g., thumbdrive, solid state drive, etc.), optical storage media (e.g., CD-ROM,DVD, Blu-Ray, etc.), or another appropriate storage media device.

As described, the inventive service may involve implementing one or morefunctions, processes, operations or method steps. In some embodiments,the functions, processes, operations or method steps may be implementedas a result of the execution of a set of instructions or software codeby a suitably-programmed computing device, microprocessor, dataprocessor, or the like. The set of instructions or software code may bestored in a memory or other form of data storage element which isaccessed by the computing device, microprocessor, etc. In otherembodiments, the functions, processes, operations or method steps may beimplemented by firmware or a dedicated processor, integrated circuit,etc.

It should be understood that the present invention as described abovecan be implemented in the form of control logic using computer softwarein a modular or integrated manner. Based on the disclosure and teachingsprovided herein, a person of ordinary skill in the art will know andappreciate other ways and/or methods to implement the present inventionusing hardware and a combination of hardware and software.

Any of the software components or functions described in thisapplication may be implemented as software code to be executed by aprocessor using any suitable computer language such as, for example,Java, C, C++, Python, or Perl using, for example, conventional orobject-oriented techniques. The software code may be stored as a set ofinstructions (or commands) on a computer-readable medium, such as arandom access memory (RAM), a read-only memory (ROM), a magnetic mediumsuch as a hard-drive or a floppy disk, or an optical medium such as aCD-ROM. Any such computer-readable medium may reside on or within asingle computational apparatus, and may be present on or withindifferent computational apparatuses within a system or network. Forexample, the set of instructions may be stored by fixed disk 620 and maybe read into system memory 606, for example, during runtime of anapplication or component.

While certain exemplary embodiments have been described in detail andshown in the accompanying drawings, it is to be understood that suchembodiments are merely illustrative of and not intended to berestrictive of the broad invention, and that this invention is not to belimited to the specific arrangements and constructions shown anddescribed, since various other modifications may occur to those withordinary skill in the art.

For ease understanding, dashed lines and/or bracketed text have beenused in the figures to assist in the clarity of this description, andmay signify the optional nature of some items (e.g., features not usedby a given implementation of the invention; features supported by agiven implementation, but used in some situations and not in others). Ofcourse, other elements that are not dashed or bracketed herein may beoptional in some embodiments, which will be obvious to those of skill inthe art.

As used herein, the use of “a”, “an” or “the” is intended to mean “atleast one”, unless specifically indicated to the contrary.

1.-20. (canceled)
 21. A method, comprising: receiving, at a computingdevice, a first transaction information for a first transaction, whereinthe first transaction information includes a first token valueassociated with a first account serving as a payment account for thefirst transaction, wherein the first token value is a substitute for afirst primary account number of the first account and includes a firsttoken issuer identifier; identifying, by the computing device based uponthe first token issuer identifier, a first entry of a plurality ofentries of a token translation table comprising a plurality of tokenissuer identifiers, each token issuer identifier associated withmultiple payment processing networks, wherein the first entry isassociated with the first token issuer identifier and identifies aplurality of payment processing networks that are eligible to processtransactions associated with the first token issuer identifier;selecting, by the computing device, a first payment processing networkof the plurality of payment processing networks to process the firsttransaction based at least in part upon the first token issueridentifier; transmitting, by the computing device, the first transactioninformation to the selected first payment processing network; andupdating, by the computing device, the token issuer identifiers in thetoken translation table with updated token issuer identifiers withoutaltering the multiple payment processing networks in the tokentranslation table to form an updated token translation table.
 22. Themethod of claim 21, wherein: at least one of the plurality of paymentprocessing networks that are eligible to process transactions associatedwith the first token issuer identifier is a credit network; and at leastone of the plurality of payment processing networks that are eligible toprocess transactions associated with the first token issuer identifieris a debit network.
 23. The method of claim 21, wherein: the firsttransaction information further includes a first verification method;each payment processing network is associated with one or moreverification methods; and the selecting the first payment processingnetwork is further based upon the first verification method.
 24. Themethod of claim 23, further comprising updating the verification methodsin the token translation table.
 25. The method of claim 23, wherein: atleast one of the one or more verification methods indicates that thecorresponding payment processing network is a personal identificationnumber (PIN) verification network; and at least one of the one or moreverification methods indicates that the corresponding payment processingnetwork is a signature verification network.
 26. The method of claim 21,wherein: the first token issuer identifier comprises a token bankidentification number (BIN); and the plurality of entries of the tokentranslation table include a plurality of token BINs.
 27. The method ofclaim 21, wherein the updated token issuer identifiers are received froman issuer of primary account numbers associated with tokens using theupdated token issuer identifiers.
 28. The method of claim 21, furthercomprising: identifying, based on the first transaction information, anaccount enhancement attribute corresponding to the first account,wherein the first payment processing network of the plurality of paymentprocessing networks to process the first transaction is further selectedbased upon the account enhancement attribute.
 29. A computing device,comprising: one or more processors; one or more network interfacescommunicatively coupled with the one or more processors; and anon-transitory computer readable storage medium, coupled to the one ormore processors, that stores instructions which, when executed by theone or more processors, cause the computing device to perform operationscomprising: receiving, at the one or more network interfaces, a firsttransaction information for a first transaction, wherein the firsttransaction information includes a first token value associated with afirst account serving as a payment account for the first transaction,wherein the first token value is a substitute for a first primaryaccount number of the first account and includes a first token issueridentifier; identifying, based upon the first token issuer identifier, afirst entry of a plurality of entries of a token translation tablecomprising a plurality of token issuer identifiers, each token issueridentifier associated with multiple payment processing networks, whereinthe first entry is associated with the first token issuer identifier andidentifies a plurality of payment processing networks that are eligibleto process transactions associated with the first token issueridentifier; selecting a first payment processing network of theplurality of payment processing networks to process the firsttransaction based at least in part upon the first token issueridentifier; transmitting, by the one or more network interfaces, thefirst transaction information to the selected first payment processingnetwork; and updating, by the computing device, the token issueridentifiers in the token translation table with updated token issueridentifiers without altering the multiple payment processing networksand their associated verification methods in the token translation tableto form an updated token translation table.
 30. The computing device ofclaim 29, wherein: at least one of the plurality of payment processingnetworks that are eligible to process transactions associated with thefirst token issuer identifier is a credit network; and at least one ofthe plurality of payment processing networks that are eligible toprocess transactions associated with the first token issuer identifieris a debit network.
 31. The computing device of claim 29, wherein: thefirst transaction information further includes a first verificationmethod; each payment processing network is associated with one or moreverification methods; and the selecting the first payment processingnetwork is further based upon the first verification method.
 32. Thecomputing device of claim 29, wherein: The first token issuer identifiercomprises a token bank identification number (BIN); and the plurality ofentries of the token translation table include a plurality of tokenBINs.
 33. The computing device of claim 29, wherein the identified firstentry further identifies a type of account associated with the firsttoken issuer identifier.
 34. The computing device of claim 29, furthercomprising: identifying, based on the first transaction information, anaccount enhancement attribute corresponding to the first account,wherein the first payment processing network of the plurality of paymentprocessing networks to process the first transaction is further selectedbased upon the account enhancement attribute.
 35. A method, comprising:determining, by a computing device, a first payment processing networkand a first associated verification method to be made eligible forprocessing transactions for a first account; searching, by the computingdevice, one or more token translation tables to identify a first entryof a plurality of entries in the one or more token translation tablescorresponding to the determined first payment processing network and thefirst associated verification method, each of the token translationtables comprising a plurality of token issuer identifiers, each tokenissuer identifier associated with multiple payment processing networks,and each payment processing network associated with one or moreverification methods, wherein the first entry is associated with a firsttoken issuer identifier and identifies a plurality of payment processingnetworks that are eligible to process transactions associated with thefirst token issuer identifier; identifying, by the computing device, thefirst token issuer identifier associated with the first entry; andcausing, by the computing device, the first token issuer identifier tobe used for a first token value generated for the first account.
 36. Themethod of claim 35, wherein causing the first token issuer identifier tobe used for the first token value generated for the first accountcomprises causing one or more payment applications or access devices tobe configured to generate tokens for the first account using the firsttoken issuer identifier.
 37. The method of claim 35, wherein causing thefirst token issuer identifier to be used for the first token valuegenerated for the first account comprises configuring token generationlogic in the computing device to generate tokens for the first accountusing the first token issuer identifier.
 38. The method of claim 35,further comprising, before determining the first payment processingnetwork, determining a need to configure payment processing for thefirst account.
 39. The method of claim 35, further comprising:determining, by the computing device, a second payment processingnetwork and a second associated verification method to be made eligiblefor processing transactions for a second account; searching, by thecomputing device, the one or more token translation tables to determinethat there is not an entry in the one or more token translation tablescorresponding to the determined second payment processing network andthe second associated verification method; selecting, by the computingdevice, a second token issuer identifier; publishing, by the computingdevice, a second token translation table entry having the selectedsecond token issuer identifier, the second payment processing network,and the second associated verification method; and causing, by thecomputing device, the second token issuer identifier to be used for asecond token value generated for the second account.
 40. The method ofclaim 35, wherein: the first token issuer identifier comprises a tokenbank identification number (BIN); and the plurality of entries of thetoken translation tables include a plurality of token BINs.